Centralized Agent Upgrade (CAU)

The Centralized Agent Upgrade (CAU) is an automatic, easy to use upgrade solution that allows you to upgrade your Agents to a different version.

If you need help, contact our support team. Our consultants are experts in upgrading AE systems and will be pleased to assist you whenever it is necessary. For more information, see Support.

This page includes the following:

Overview

Any user with the necessary authorizations can carry out a Centralized Agent Upgrade (CAU) in any Client of your system for the following Agents:

  • Windows

  • x64 Linux

  • UNIX (AIX, LINUX, SOLARIS, 64bit ZLINUX)

  • SAP

  • SQL

  • PeopleSoft

  • Rapid Automation (RA)

  • Intelligent Automation (IA)

  • TLS Gateway

For more information, see Installing the Agents.

Since there is a switch between Agent versions at one point of the process, a real zero downtime is not possible.

The Agent resources (binaries) required for the CAU are attached to and delivered with Storage (STORE) objects. These Storage objects are delivered in Packs and are available for each released Agent version. You can download them from https://marketplace.automic.com/.

When installing an Agent on a UNIX system, make sure that the libstdc++.so and libgcc_s.so libraries are available, so that the respective Agent can use them. They are no longer delivered with the Agent's .tar balls but with the Automic Automation offering under External. Resources/unix_libraries/unix_libraries.tar.gz. First, untar the component's .tar file. Then, untar the libraries' tar file and copy the files relevant for your Operating System to the component's bin folder. Additionally, use the ln -s ./libstdc++.so.6 command to create symbolic links for the libraries in the bin folder.

When upgrading Windows or x64 Linux Agents, you can also download a JRE Pack (PCK.AUTOMIC_CAU_JRE_<OS>) which contains a new Java installation. When the Pack is installed, the system checks if there is a JRE directory available already. If so, the system deletes it and replaces it with the new one. If there is, the system uses it to start the Agent with the new JRE installation instead of the default definition of the JAVA_HOME or JAVA_PATH environment variables. If there is no JRE directory available, the system uses the JAVA_HOME or JAVA_PATH definition.

Important!

  • To import CAU pack versions older than the installed ones, make sure you delete the current CAU pack version first.

  • Make sure you also download Packs for the version from which you are upgrading, just in case you need to revert to it.

You can define a maximum size allowed for Packs using the PM_MAX_PACK_SIZE_MB key either in the UC_CLIENT_SETTINGS or in the UC_SYSTEM_SETTINGS variables. The value defined in the UC_CLIENT_SETTINGS variable overrides the value defined in the UC_SYSTEM_SETTINGS variable.

Once you have downloaded the relevant Packs, you have to install them in Client 0. You can install them from the Packs page in the Administration perspective which is only visible if the Plugin Manager is installed.

More information:

Notes:

  • Make sure that the Packs you download and install for the CAU are from trusted sources. Users that have the authorization to conduct a CAU are potentially able to import malicious files as well.

  • Do not change the names of the objects that you download and install. The specific name pattern is used to identify the types and versions of the resources.

    If the names of these objects do not match the pattern, the Agent version is not displayed in the update list.

  • Do not change the content of the Agent resources (binaries). It is released by CA Automic and must not be altered.

Important!

  • It is not possible to carry out a Centralized Agent Upgrade (CAU) parallel to a Zero Downtime Upgrade.

  • Once an Agent is configured for a Centralized Agent Upgrade (CAU), it is no longer possible to upgrade it manually. After changing the version of an Agent manually, the Agent (together with the ServiceManager) updates/rolls back to the target version defined.

    Please contact our support department if you need help reverting the status of an Agent after a CAU or perform a CAU to the latest version to avoid continuously repairing the Agent. For more information, see Support.

Upgrading from GSS to TLS/SSL Agents

The communication between the Automation Engine and the different components uses TLS/SSL through a secure WebSocket (WSS). These components establish a connection with the Java communication process (JCP) and/or the REST process (REST), which use trusted certificates to prove their identity to other communication partners, such as Agents.

The Windows, UNIX and Java agents can use different parameters in their corresponding INI file to define how to handle the certificates.

Note: The TLS/SSL implementation does not apply to the HP-UX and 32 bit ZLINUX Agents, as they are no longer supported.

More information:

During the Centralized Agent Upgrade (CAU), the system adds additional properties to the respective Agent INI file, which are required to connect to the Java communication process (JCP) and to handle the relevant certificates.

The following properties are added:

  • TCP/IP

    connection = jcphost:8443

    Default value for the JCP connection.

  • [AUTHORIZATION]

    trustedCertFolder = ./certificates

    Path to the folder in which the trusted certificates are stored.

You can also override the default value of the connection= parameter when using the CAU to upgrade a GSS Agent to TLS/SSL. To do so, use the JCP_ENDPOINT_CAU_OVERRIDE system variable. For more information, see JCP_ENDPOINT_CAU_OVERRIDE.

During the Centralized Agent Upgrade (CAU), the configuration value for the old cp= parameter (cp = host:port) is not removed from the INI file in case you have to perform a rollback. You can either ignore this parameter or remove it manually from the INI file.

To start a TLS/SSL Agent after the Centralized Agent Upgrade (CAU), the Agent also requires the JCP certificate (jcp.cer) to connect to the Automation Engine. This certificate is not part of the CAU Storage object but is added dynamically to the upgrade resources by the server.

When you used certificates signed by a CA, the certificates are stored in the respective Java or OS store by default; that is the Java trust store for Java components and Java Agents, the Windows OS store for Windows Agents, or the TLS/SSL store for UNIX Agents. In this case, you only have to check that the root certificates already are in the respective store.

If the relevant certificates are not there and you want to import them, you can use OS or Java specific tools for that purpose, such as Keytool, cert-manager, OpenSSL and such. For more information on how to use those tools, please refer to the respective product documentation.

If you do not want to use the default locations for the components and Agents listed above, make sure you use the trustedCertFolder=, agentSecurityFolder=, and keyPassword= parameters (if applicable) in the respective configuration (INI) file to define the path to the folder where the trusted certificates are stored.

In the Automic Automation Kubernetes Edition, the JCP by default uses a generated, self-signed certificate within the Kubernetes cluster. When you migrate from an on-premises installation to AAKE and use the CAU to upgrade your Agents, they automatically receive the certificates from the JCP within the cluster. This means that the Agents cannot establish the connection to the cluster because they need to connect to an HTTPS load balancer and not the JCP directly. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

However, you can use the CAU_INCLUDE_SERVER_CERTIFICATES parameter in the UC_SYSTEM_SETTINGS variable to stop the Automation Engine from automatically sending the server certificates to the Agents during CAU. For more information, see CAU_INCLUDE_SERVER_CERTIFICATES.

This applies to the following Agents:

For Agents not mentioned in the list above, see TLS Gateway and Installing the TLS Gateway.

See also: